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SECURE SESSION MANAGEMENT AND AUTHENTICATION FOR WEB SITES 

ABSTRACT 

5 The present invention comprises a system and method for secure session management and 

authentication between web sites and web clients. The method includes both secure and non-secure 
communication protocols, means for switching between secure and non-secure communication 
protocols, a session cookie and an autocode cookie. The session cookie is used for session 
management and the authcode cookie is used for authentication. The session cookie is transmitted 
10 using a non-secure communication protocol when the web client accesses a non-secure web page, 
whereas, the authcode cookie is transmitted using a secure communication protocol when the web 
client accesses a secure web page. Session management architecture and usage of two distinct 
cookies along with both secure and non- 
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SECURE SESSION MANAGEMENT AND AUTHENTICATION FOR WEB SITES 

FIELD OF THE INVENTION 

The present invention pertains to communication between web sites and web clients, and in 
particular, to session management and authentication means, using secure and non-secure 
communication protocols, for sessions between web sites and web clients. 



BACKGROUND OF THE INVENTION 

Many businesses have embraced the Internet as a way to reduce expenses and advertise their 

10 services or products to a wide consumer base. These businesses (i.e. web merchants) have setup 
online shopping web sites to sell soft goods, such as information or software, and/or hard goods. 
This benefits many consumers (i.e. web clients) who increasingly use the Internet because of the ease 
with which they can shop online. In fact, online transactions between web merchants and web 
clients are becoming increasingly more numerous. 

1 5 Although e-commerce is convenient, it is not problem free since communication between a 

web client's web browser and an e-commerce web site is based on HTTP (HyperText Transfer 
Protocol). HTTP is stateless which means that the HTTP protocol does not maintain information 
about a web client from one visit to the next. As a result, the e-commerce web site must take steps 
to remember a web client who revisits at a later date. Another problem is that HTTP is not secure 

20 which is troublesome since a web client must provide sensitive information, such as a credit card 
number or an account number, in order to pay for and receive products. An unauthorized user may 
be watching the HTTP communication to steal this sensitive information. The unauthorized user 
could then order goods under the web client's identity and request that the goods be sent to a 
different address or access sensitive web client data such as address and credit card information. 

25 To correct these problems, an e-commerce web site must allow for authentication and session 

management while holding a conversation with a web client. Further, a secure communication 
protocol must be used when sensitive information is transmitted between the web client and the e- 
commerce web site. Session management allows a web site to remember a web client between 
different login sessions whereas authentication is a security measure which assures a web site that 

30 a request came from the same web client who originally logged onto the web site. A secure 
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communication protocol encrypts the data transmitted between the e-commerce web site and a web 
client. To accomplish authentication and session management, one may utilize HTTP Basic 
Authentication, Name- Value Pair Authentication or session cookies. 

HTTP Basic Authentication always requires a web client to logon before session 
management. To this end, a login window will pop open when the web client first accesses the web 
site. This login window is not easily customizable by the web site administrator. Thus, there is no 
support for guest client access of secure web pages because the web server forces the web client to 
log on. Consequently, most e-commerce web sites do not use HTTP Basic Authentication. 

Name-Value Pair Authentication involves embedding security information in every URL 
(Uniform Resource Locator) or in the data in every web page on the e-commerce web site. 
Consequently, the web site developers need to handle authentication for each web page by passing 
authorization data from one web page to another. This authorization data may be easily lost when 
the web client jumps from a secure web page to a non-secure web page. Name-value pairs also do 
not support guest client access of secure web pages because the web server forces the web client to 
register or log on when accessing a secure web page. The authorization data is also not secure if it 
is appended to the web page URL since it may be exposed in the web server's log or shown on the 
web client's web browser. In addition, authorization data included in web page data is not secure 
since it may be seen by viewing the web browser cache files. 

Cookies are the most popular method for session management and authentication between 
a web site and a web client. Cookies are stored and retrieved on the web client's computer. 
Permanent cookies are stored on the computer's hard drive meanwhile temporary cookies are stored 
in volatile memory and erased once the web session is finished. The Netscape Navigator™ web 
browser stores permanent cookies in a text file (i.e. cookie.txt) with one line in the file being used 
per cookie, whereas the Microsoft Internet Explorer™ web browser uses a separate text file for each 
permanent cookie. Cookies are designed to provide useful information about the web client to the 
web server such as which web pages the web client last accessed. Cookies can also be used to 
provide some pre-determined level of web client access and customization at a web site. The cookie 
also contains a description of the set of URLs for which the cookie is valid. Any future HTTP 
requests made by the web client, which coincide with the set of URLs contained in a cookie, will 
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include a transmittal of the cookie's current value from the web client back to the web server. 

The first time that a web client requests information from a web server, that makes use of 
cookies, the web server delivers the requested information along with a cookie. The cookie is sent, 
from the web server to the web client, by including a Set-Cookie header as part of an HTTP 
5 response. The Set-Cookie header is generated by a CGI script and contains the following attributes: 
NAME, DATE, PATH, DOMAIN and SECURE. The NAME attribute contains web client related 
data which is used by the web site. There can be many NAME attributes in a cookie and many Set- 
Cookie headers can be issued in a single web server response. The DATE attribute specifies a date 
which indicates when the cookie will expire. The PATH attribute specifies the subset of URLs in 

10 a domain for which the cookie is valid. The DOMAIN attribute is the internet domain name of the 
web site. The SECURE attribute indicates the conditions under which the cookie is transmitted. For 
instance, if the cookie's SECURE attribute is marked as secure then it will only be transmitted if the 
communication channel between the web server and the web client is secure. 

Cookie based session management must incorporate a secure communication protocol to 

1 5 prevent unauthorized users from stealing sensitive data contained in the cookie. One such protocol 
is HTTPS (HTTP over SSL). The acronym SSL stands for Secure Socket Layer protocol which is 
an industry standard for transmitting information securely while using HTTP. HTTPS includes 
provisions for web server authentication (verifying the web server's identity to the web client), data 
encryption and web client authentication (verifying the web client's identity to the web server). 

20 Each HTTPS enabled web server is installed with both a coder and a decoder which utilize keys and 
data encryption that are unique. The data encryption, which converts words and numbers into a 
series of alpha-numeric characters, can only be unlocked by the decoder that comes with the web 
server licensed to the web merchant. The level of security depends on whether a 40 or 128 bit key 
is used. The difficulty in cracking the code (or the key) increases with the number of bits contained 

25 in the key. Cookie-based session management and authentication schemes have been described in 
the prior art. 

U.S. patent 5,875,296 discloses a method for providing secure access to a distributed file 
system via a web site. The method utilizes a single cookie containing a user identifier to access files 
in the distributed file system. This cookie allows the user to avoid having to re-enter a user ID and 
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password every time information on the distributed file system is accessed. This method is also 
specific to a distributed file system and does not use a secure communication protocol. 

U.S. patent 6,047,268 discloses a system and method for authenticating web clients who 
make online purchases. Authentication is provided by a single cookie that contains a static portion 
5 identifying the web client's account number and an encrypted dynamic portion which identifies the 
last transaction made by the web client. This cookie is updated after each new transaction with a 
new dynamic portion, however, this patent discloses using sensitive information in the cookie and 
permanent cookie storage on the web client 9 s computer system. In addition, the e-commerce method 
disclosed in this patent is not flexible enough to allow guest clients to perform online shopping; all 

10 web clients must register in order to shop online. U.S. patent 6,047*268 does disclose the use of 
HTTPS but does not state if HTTPS is used exclusively or whether the communication protocol 
switches between HTTPS and HTTP. 

U.S. patent 6,076,069 discloses a system and method for redeeming electronic coupons. 
When a web client visits a web site, which advertises promotional material from a web merchant, 

1 5 a coupon is stored on the web client's computer system in the form of a cookie. If the web client 
later visits the web merchant's web site, the web site will recognize the electronic coupon stored in 
the cookie and offer a discount to the web client. This patent does not teach the use of a secure 
communication protocol. Furthermore, this patent discloses using sensitive information in the 
cookies, such as the web client's account number, and the use of persistent cookies (i.e. the cookies 

20 are stored permanently on the web client's computer system). Both of these features raise security 
issues. 

The exclusive use of HTTPS entails a performance degradation because of the encoding and 
decoding which is done each time a web page is accessed. This is inefficient since many web pages, 
such as product catalog web pages which incidentally obtain the most visits from web clients, do not 
25 require protection. In addition, using HTTPS for the web site home page URL can be inconvenient 
for a web client since the web client is not accustomed to using https' in place of http' in a web 
site's URL. Furthermore, switching between HTTP and HTTPS can be troublesome because 
currently when a web client logs onto a web site using HTTPS, a cookie is issued to authenticate the 
web client, however, if the web client later browses a non-secure web page at the web site using 
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HTTP, the same cookie is sent to the web client in clear text. At this point an unauthorized user can 
steal the cookie. Thus, using a single cookie under these circumstances jeopardizes the security of 
the web site. 

Accordingly, there is a need for an improved secure session management and authentication 
5 method, using cookies, to protect both the web site and the web client from unauthorized users. The 
present invention addresses these needs. 

SUMMARY OF THE INVENTION 

The present invention provides a method for secure session management and authentication 
10 between a web site and a web client, the web site having secure and non-secure web pages, the 
method having the steps of utilizing a non-secure communication protocol and a session cookie 
when the web client requests access to non-secure web pages; and utilizing a secure communication 
protocol and an authcode cookie when the web client requests access to secure web pages. 

Preferably, the method further includes the steps of requesting the session cookie from the 
1 5 web client when the web client requests access to non-secure web pages and verifying the requested 
session cookie; and requesting the authcode cookie from the web client when the web client requests 
access to secure web pages and verifying this requested authcode cookie. 

Preferably, the method further includes alternating between the secure and non-secure 
communication protocol when the web client alternates requests for access to secure and non-secure 
20 web pages. 

In another aspect, the present invention is a system for secure session management and 
authentication between a web site and a web client. The system includes a web server, a web client 
and a communication channel. The web server is coupled to the web client via the communication 
channel. The web server has a web site which includes secure and non-secure web pages; a non- 
25 secure communication protocol and a session cookie for allowing the web client access to non-secure 
web pages; and a secure communication protocol and an authcode cookie for allowing the web client 
access to secure web pages. 

Preferably, the web site further includes verification means for verifying the session cookie 
which is requested from the web client; and verification means for verifying the authcode cookie 
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which is requested from the web client. 

Preferably, the web server further includes a security alternating means for alternating 
between the non-secure and secure communication protocol. 

It will be appreciated by those skilled in the art that the invention can be embodied in a 
5 computer program which can be stored in storage or transmitted as a signal, such as on a modulated 
carrier signal for use in a computer system, or on a network such as the Internet for use in a computer 
system. 

BRIEF DESCRIPTION OF THE FIGURES 

1 0 For a better understanding of the present invention, and to show more clearly how it may be 

carried into effect, reference will now be made by way of example to the accompanying drawings 
in which: 

Fig. 1 is a schematic diagram of the components of the present invention; 
Fig. 2 is a data structure diagram of the fields contained in the USER_SESSION table; 
1 5 Fig. 3 is a data structure diagram of the fields contained in the URL_REGISTRY table; 

Fig. 4a and Fig. 4b together comprise a flowchart of a first usage scenario of the present 
invention; 

Fig. 5a, Fig. 5b and Fig. 5c together comprise a flowchart of a second usage scenario of the 
present invention; and 

20 Fig, 6a and Fig. 6b together comprise a flowchart of a third usage scenario of the present 

invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A secure session management system in accordance with the present invention is shown 
25 generally as 10 in Figure 1. System 10 comprises web server 12, communication channel 14, and 
web client 16. Web server 1 2 includes web server software package 1 8 for creating and maintaining 
web site 20. Web site 20 includes web pages 22, database 24 and cookie generator 26. Web pages 
22 comprises Type I web pages 28 and Type II web pages 30. Type II web pages 30 are further 
subdivided into Type Ila web pages 32 and Type lib web pages 34. Database 24 comprises tables 
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which are needed for proper operation of web site 20, however the tables of interest for the present 
invention are USER_SESSION table 36 and URL_REGISTRY table 38. Cookie generator 26 can 
produce session cookie 40 and authcode cookie 42. Web client 16 is considered as either guest client 
44 or registered client 46 while maintaining a session with web site 20. Hereafter, in the 
5 specification and claims, the term web client' refers to either guest client 44 or registered client 46. 
There may be a plurality of web clients 16 accessing web site 20 at the same time, however, only 
one web client 16 is shown in Figure 1 for the sake of simplicity. As will be understood by one 
skilled in the art, web client 16 further comprises a web browser (not shown), to permit web client 
16 to access and view the content of web site 20. 

10 Communication channel 14 couples web client 16 to web server 12 and is preferably a 

TCP/IP (Transfer Communications Protocol/Internet Protocol) based network such as the Internet. 
TCP/IP is a family of protocols that allow cooperating computers to share resources or data across 
a network. As one skilled in the art will appreciate, web client 16 may use any of a plurality of 
means to connect to communication channel 14. For instance, web client 16 may connect to 

15 communication channel 14 through an Internet access provider via a phone, cable or wireless 
modem. Alternatively, the connection may also be through a cable TV network or another access 
medium. Communication channel 14 may also be an Intranet, a local area network, or a wide area 
network which is connected directly to the Internet 

Web server 1 2 uses HTTP (HyperText Transport Protocol), a standard application protocol, 

20 to allow web client 1 6 access to web pages 22, files or other data located on web site 20. Web pages 
22 are in HTML (HyperText Markup Language) format which is an industry standard web page 
description language. HTML provides basic document formatting and allows web server 12 to 
specify links to other web sites and/or files. Alternatively, other formats may be used for web pages 
22 such as ASP (Active Server Page) or JSP (Java Server Page). Web server 1 2 also contains a web 

25 server software package 18 which aids in the creation and maintenance of web site 20. One such 
web server software package 18 is WCS Version 5.1™ sold by the IBM Corporation. 

Web site 20 contains Type I web pages 28 and Type II web pages 30. Type I web pages 28 
are identical for all web clients 16 and include static and some dynamically generated web pages. 
Alternatively, Type II web pages 30 are unique for a given web client 1 6 and include shopping cart 
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web pages and account information web pages. Shopping cart web pages contain details about 
impending purchases that web client 16 will make whereas account information web pages contain 
web client information such as address information. Type II web pages 30 can be further subdivided 
into Type Ha web pages 32 and Type lib web pages 34. Type Ha web pages 32 are secure web pages 
5 containing sensitive information which require protection from unauthorized users whereas Type 
lib web pages 34 are non-secure web pages since they contain information that is not important 
enough to be protected from unauthorized users. The boundary between Type Ha web pages 32 and 
Type lib web pages 34 is not distinct and depends on the security policy defined by the administrator 
of web site 20. For illustrative purposes, an example of a Type Ila web page 32 is a credit card input 

10 web page and an example of a Type lib web page 34 is a product description web page. 

In the preferred embodiment of the present invention, database 24 is a relational database 
containing a plurality of tables necessary for the management and operation of web site 20. As one 
skilled in the art will recognize, database 24 need not be resident on web site 20 and may indeed 
comprise a plurality of files on a plurality of systems. Furthermore, one skilled in the art will 

1 5 appreciate that many types of database structures may be utilized, such as object-oriented databases, 
network databases, hierarchical databases or even a collection of flat files. 

In the present invention, database 24 contains, for the purposes of authentication and session 
management, USER_SESSION table 36 and URLJREGISTRY table 38. USER_SESSION table 
36 is used to manage session information for web client 1 6 while URLJREGISTRY table 3 8 is used 

20 to determine if a secure or non-secure communication protocol is needed when web client 16 
requests access to a particular web page 22 on web site 20. 

Each record in USER_SESSION table 36 contains information on aparticular web client 1 6. 
This information is stored in a plurality of fields contained in USER_SESSION table 36 (see Figure 
2). In the preferred embodiment of the present invention, these fields are: USER_ID 50, 

25 SESSION© 52, SESSION JTIMESTAMP 54, AUTOCODE 56, AUTHCODE_TIMESTAMP 58, 
USER_TYPE 60, LOGINJD 62 and PASSWORD 64. For a particular web client 16, USERJD 
50 contains a unique key value to identify web client 16 in USER_SESSION table 36. 
SESSIONJD 52 contains a string to identify the current web session between web client 1 6 and web 
site 20, SESSION_TIMESTAMP 54 contains a timestamp indicating when session cookie 40 was 
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created or modified. AUTHCODE 56 contains the autocode (i.e. authorization code) for web client 
1 6. AUTHCODE_TIMESTAMP 58 contains a timestamp indicating when autocode cookie 42 was 
created or modified. USERJTYPE 60 indicates whether web client 16 is a guest client 44 or a 
registered client 46. If web client 16 has registered with web site 20 then LOGINJD 62 contains 
5 a login ID and PASSWORD 64 contains a password. Alternatively, other fields may be added to 
USER_SESSION table 36 to provide more information about web client 16 or to provide more 
functionality or to provide a higher level of security for web site 20. 

Each record in URL_REGISTRY table 38 contains information on a different web page 22 
on web site 20. Referring now to Figure 3, toe fields preferably contained in URL_REGISTRY 

1 0 table 38 are URL_ADDRESS 70 and HTTPS JFLAG 72. For a particular web page 22 on web site 
20, URL_ADDRESS 70 contains the URL address of web page 22 and HTTPS_FLAG 72 contains 
a value of 1 if web page 22 requires a secure communication protocol or a value of 0 if web page 22 
does not require a secure communication protocol. Alternatively, other fields may be added to 
URL_REGISTRY table 38 to provide more information about web page 22 or to enhance the 

15 security level of web site 20. 

Web server 12 allows web client 16 to be either a guest client 44 or a registered client 46 
while accessing web site 20, however, web client 16 is a guest client 44 by default each time web 
site 20 is accessed. Web site 20 allows anonymous guest client status for web clients 16 who only 
want to browse web site 20 or make one purchase and then never access web site 20 again. Guest 

20 client 44 does not need a login ID or password for web site 20, however, guest client 44 can browse 
web site 20, access both secure and non-secure web pages, and order products. Guest client 44 must 
continually re-enter client specific information such as a shipping address and a credit card number 
on each purchase at web site 20. Futhermore, guest client 44 can not revisit web site 20 and inquire 
about previous purchases (i.e. the order history). 

25 A registered client 46 is a web client 1 6 who has registered with web site 20 and has logged 

in as a registered client Registered clients can set up a customized account for a customized online 
shopping experience. Guest client 44 can register by completing a registration form (which can be 
customized by the administrator of web site 20). The registration form could request toe web client's 
name, residential address, e-mail address, preferred method of payment, login ID and password as 

CA9-2000-0054 9 



CA 02327078 2000-11-30 



well as other information. This information is stored in a table, containing web client information, 
in database 24 for future retrieval or modification. Credit card information specific to registered 
client 46 is also stored in database 24. By storing this information, registered client 46 is not 
required to reenter a credit card number with each purchase. 

5 Web server 12 has cookie generator 26 which generates session cookie 40 and authcode 

cookie 42 which are transferred between web server 12 and web client 16. The communication 
protocol can be either HTTP or HTTPS when session cookie 40 is transmitted, however, when 
authcode cookie 42 is transmitted the communication protocol must be HTTPS. In the preferred 
embodiment, web site 20 utilizes HTTPS with either a 40 or 128 bit key as the secure 

10 communication protocol. The administrator of web site 20 decides which key size is used. 
Preferably a 1 28 bit key should be used. It is not the intent of the inventor to restrict the key size to 
40 or 128 bits but rather it is instead a suggestion based upon the common technology in use at the 
time of the invention. HTTPS is implemented on many web browsers such as Netscape Navigator™, 
Secure Mosaic™ and Microsoft Internet Explorer™. HTTPS is also implemented on web servers 

1 5 made by Netscape, Microsoft and IBM Quarterdeck. 

Session cookie 40 is responsible for session management, while authcode cookie 42 is 
responsible for authentication. In the preferred embodiment, session cookie 40 and authcode cookie 
42 are temporary cookies which are erased when web client 16 closes their web browser. 
Alternatively, one may define session cookie 40 to be permanently stored on the computer system 

20 of web client 1 6, however, authcode cookie 42 should always be temporary for security reasons. 

As described earlier, a cookie comprises the following attributes: NAME, DATE, PATH, 
DOMAIN and SECURE. The data used in the NAME attribute of session cookie 40 preferably 
comprises data contained in USERJD 50, SESSIONJD 52 and SESSION JTMESTAMP 54. 
Other optional information (not shown) may be included in the NAME attribute of session cookie 

25 40 if so desired. The data from USERJD 50 is a unique key used to access the data for web client 
16 stored in USER_SESSION table 36. SESSIONJD 52 contains a string which is randomly 
generated by a cryptographic random number generator. The cryptographic random number 
generator has the essential property that no one can predict the value of the number that will be 
generated. In the preferred embodiment of the present invention, the cryptographic random number 
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generator is the rand() function in the C standard library which is available in all commercial C 
compilers. Although the randO function only generates numbers, random strings may also be 
generated by mapping the randomly generated number to a letter of the alphabet by dividing the 
randomly generated number by 26 and mapping the remainder from this division operation to a letter 
5 whereby a remainder of 0 would map to the letter A, a remainder of 1 would map to the letter B, a 
remainder of 2 would map to the letter C and so on. For example purposes, if a string with 10 
characters is desired then this process of number generation, division by 26 and mapping of the 
remainder to a letter is repeated 10 times. The data from SESSION_TIMESTAMP 54 is a 
timestamp indicating the time at which session cookie 40 was created or modified which occurs 

10 when web client 1 6 either logs on as a guest client 44, registers to become a registered client 46 or 
logs on as a registered client 46. The data from SESSION_TIMESTAMP 54 is included in session 
cookie 40 to provide time sensitive information which increases the security of web site 20 by 
allowing session cookie 40 to be more unique and thus harder to duplicate. 

The data contained in the NAME attribute in session cookie 40 is generated by appending 

15 the data from SESSION_TIMESTAMP 54 to SESSIONJD 52, applying a one-way MD5 hash 
function and appending the result of the MD5 hash function to the data from USERJD 50. The 
MD5 one-way hash function takes a variable length input string and converts it to a 128 bit binary 
sequence. The MD5 one-way hash function is designed such that it is hard to reverse the hash 
process to obtain the input string that was hashed. In the preferred embodiment, the MD5 one-way 

20 hash function from the BSAFE™ toolkit developed by RSA Laboratories is used. The PATH 
attribute of session cookie 40 is specified as /* which means that the web browser of web client 1 6 
must send session cookie 40 back to web server 12 when web client 16 requests access to any URL 
path on web site 20. The EXPIRES attribute is not specified since session cookie 40 is temporary 
and the DOMAIN attribute is not specified since the web browser of web client 16 will use the 

25 domain name of web server 12. The SECURE attribute is left unspecified since a secure 
communication protocol is not required when session cookie 40 is transmitted between the web 
browser of web client 16 and web site 12. If web client 16 is a registered client 46, then the next 
time web client 16 accesses web site 20, the data contained in SESSIONJD 52 is used to generate 
session cookie 40, however, if web client 1 6 is only a guest client 44 then new data from stored in 
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SESSION JD 52 is used when session cookie 40 is generated. 

The data used in the NAME attribute of authcode cookie 42 preferably comprises the data 
stored in AUTHCODE 56 and AUTHCODEJTIMESTAMP 58. Other optional information (not 
shown) may be included in the NAME attribute of authcode cookie 42 if so desired- The data in 
5 AUTHCODE 56 is preferably a randomly generated string or integer generated by the same 
cryptographic random number generator used to generate the data contained in SESSIONJD 52 for 
session cookie 40. Alternatively, a different cryptographic random number generator may be used. 
The data contained in AUTHCODEJTIMESTAMP 58 is a timestamp indicating the time at which 
authcode cookie 42 was created or modified which occurs when web client 1 6 either accesses secure 

10 web page 32 as a guest client for the first time, became a registered client 46 or logs onto web site 
20 as a registered client 46. The data contained in AUTHCODEJTIMESTAMP 58 is included in 
authcode cookie 42 for the same security purposes described above for session cookie 40. 

The data in the NAME attribute of authcode 42 is generated by appending the data stored in 
AUTHCODEJTIMESTAMP 58 to AUTHCODE 56 and applying the one-way MD5 hash function. 

15 The EXPIRES attribute is not specified since authcode cookie 42 is temporary and the DOMAIN 
attribute is not specified since the web browser of web client 1 6 will use the domain name of web 
server 12. The SECURE attribute is specified since a secure communication protocol is required 
when authcode cookie 42 is transmitted between the web browser of web client 16 and web server 
12. The PATH attribute of authcode cookie 42 is specified as /* which means that the web browser 

20 of web client 1 6 must send authcode cookie 42 to web server 12 whenever web client 16 requests 
access to any URL path on web site 20. However, since the SECURE attribute is set, authcode 
cookie 42 is only sent when the communication protocol used by the web browser of web client 16 
is secure. 

Web client 16 can either be a guest client 44 or a registered client 46 when accessing web 
25 site 20. By default, web client 1 6 is considered a guest client 44 every time web client 1 6 accesses 
web site 20. Web client 1 6 can then remain a guest client 44 or register to become a registered client 
46, or log on as a registered client 46 if web client 16 had previously registered with web site 20. 
In all instances, web client 1 6 uses a web browser to view web pages 22 on web site 20. The web 
browser could be Netscape Navigator™, Microsoft Internet Explorer™ or any other suitable web 
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browser. Web client 16 connects to web site 20 by requesting its URL which is a special syntax 
defining a network address. When web client 16 requests a URL, the web browser of web client 1 6 
will compare the requested URL with all cookies stored on the computer system of web client 16 
and a line containing the name/value pairs of all matching cookies will be included in the request 
5 for web site 20. If web client 1 6 has disabled cookie use in their web browser, then web client 1 6 
will not be able to access web site 20. In this case, web server 12 will inform web client 16 that 
cookie usage must be enabled on their web browser. 

The method of the present invention relies on several component processes and basic 
definitions. Firstly, web site 20 must enforce the use of HTTPS when web client 16 requests access 
10 to secure web pages 32. Secondly, the login and registration web pages on web site 20 are defined 
to be secure web pages 32. The component processes will now be shown in pseudocode format and 
discussed. 

The pseudocode for the process by which web site 20 determines whether a secure or non- 
secure communication protocol is required between web client 1 6 and web site 20 is shown below 
15 as Process A. 



web client 16 requests web page 22 
determine URL of requested web page 22 
obtain corresponding value in HTTPS_FLAG 72 
if value in HTTPS_FLAG 72 = 0 

process request of web client 16 
elseif value in HTTPS_FLAG 72 = 1 

instruct web client 16 to go to secure web site URL 
web client 16 uses HTTPS 
process request of web client 16 
Process A: Determination of Need for Secure or Non-Secure Communication 
Protocol. 

Process A begins when web client 16 requests access to web page 22 on web site 20. Web 
30 server 1 2 then determines the URL of web page 22 and uses it as a key for URL_REGISTRY table 
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38 to obtain the value contained in HTTPSJFLAG 72 corresponding to web page 22. If the value 
contained in HTTPS_FLAG 72 is zero then HTTPS is not needed and the request of web client 16 
is processed regardless of whether web client 16 is using HTTP or HTTPS. Otherwise, if 
HTTPS_FLAG 72 contains a value of one, then web server 12 instructs the web browser of web 
5 client 1 6 to go to the secure web site URL corresponding to web page 22. This is done by providing 
the secure web site URL in the HTTP header that web server 12 sends to the web browser of web 
client 16. The web browser of web client 16 knows to use HTTPS because https* is contained in 
the URL that was sent. The web browser of web client 1 6 then uses HTTPS to request access to web 
page 22 after which the request is processed. In the preferred embodiment, the communication 

1 0 protocol must be switched from HTTP to HTTPS if access to secure web page 32 is requested while 
web client 16 is using HTTP, however, if web client 16 is using HTTPS while requesting access to 
non-secure web page 34 then the communication protocol is left as is. Alternatively, the 
administrator of web site 20 can change this feature, by using web server software 18, such that if 
HTTPS is being used and web client 16 requests access to non-secure web page 34 then the 

1 5 communication protocol is switched to HTTP. 

Another process used to create a guest client account or a session cookie when web client 1 6 
either accesses web site 20 for the first time or revisits web site 20, does not have session cookie 40 
and is not a registered client 46. The pseudocode for this process is shown as Process B. 



create user entry in USER_SESSION table 36 
mark USERJTYPE 60 to show guest user status 
generate data for SESSION_ID 52 
generate data for SESSION JTIMESTAMP 54 
.apply one-way hash function 
generate session cookie 40 
send session cookie 40 to web client 16 



30 



Process B: Create Guest Account and Session Cookie. 

Process B begins when web server 12 creates a guest client entry in USER_SESSION table 36 by 
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adding a new record. The creation of a new record in USER_SESSION table 36 includes generating 
a new key value and storing it in USERJD 50 in the newly created record in USER_SES SION table 
36. Next guest' or another suitable identifier is stored in USERJTYPE 60 for the newly created 
guest client entry. The data, preferably a string, for SESSION_ID 52 is then randomly generated 
by the cryptographic random number generator previously described and stored in SESSION_ID 52. 
Next, the data for SESSIONJTIMESTAMP 54 is calculated and stored in SESSION_TIMESTAMP 
54. The one-way MD5 hash function is then preferably applied to the concatenation of the data 
contained in SESSIONJD 52 and SESSION JTIMESTAMP 54 (the data contained in 
SESSION_TIMESTAMP 54 is appended to the data contained in SESSIONJD 52). Alternatively, 
a different hash function may be used. Numerous hash functions are well known in the art, a 
fundamental reference being The Art of Computer Programming, Volume 3: Searching and 
Sorting", by Donald E. Knuth in which Professor Knuth provides a seminal discussion on the 
mathematics of creating a hash function. The result of the MD5 hash function is concatenated with 
the data contained in USERJD 50 and stored in the NAME attribute of session cookie 40. Web 
server 12 then assigns the other attributes of session cookie 40 and sends session cookie 40 to the 
web browser of web client 16. 

Another component process is used for the creation of authcode cookie 42. This usually 
occurs when guest client 44 requests access to secure web page 32 and is using the HTTPS 
communication protocol but does not have authcode cookie 42. The pseudocode for this process is 
shown as Process C. 



obtain data in session cookie 40 corresponding 


to 


USER_ID 50 




if AUTHCODE 56 != " 




deny request 




else 




generate data for AUTHCODE 56 




generate data for AUTHCODEJTIMESTAMP 58 




apply one-way hash function 




generate and send authcode cookie 42 to web 


client 16 



Process C: Creating an Authcode Cookie. 
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Process C begins by extracting data from the NAME attribute of session cookie 40 
corresponding to the data stored in USER_ID 50. This data is then used as a key into 
USERJSESSION table 36 to determine whether an authorization code is contained in AUTOCODE 
56 for guest client 44. If an authorization code is contained in AUTOCODE 56 then web client 16 
5 may be an unauthorized user so web server 1 2 denies the request, generates an error web page and 
sends this error web page to the web browser of guest client 44. Alternatively, if AUTOCODE 56 
is empty, then data for AUTOCODE 56, preferably a string or an integer, is randomly generated by 
the cryptographic random number generator previously described. This data is then stored in 
AUTOCODE 56. Next, the current timestramp is stored in AUTHCODE_TIMESTAMP 58. The 
1 0 MD5 one-way hash function is then preferably applied to the concatenation of the data contained in 
AUTHCODE 56 and AUTHCODE JTMESTAMP 58 (the data contained in 
AUTOCODE JTIMESTAMP 58 is appended to the data contained in AUTHCODE 56). 
Alternatively, a different hash function may be used as described above. The result of the MD5 hash 
function is then stored in the NAME attribute of authcode cookie 42. The rest of the attributes of 
15 authcode cookie 42 are assigned and web server 12 then sends authcode cookie 42 to the web 
browser of guest client 44. 

Another component process handles the case when guest client 44 decides to become a 
registered client 46 while browsing web site 20. The pseudocode is shown below as Process D. 
direct guest client 44 to registration web page 
obtain data in session cookie 40 corresponding to 
USER_ID 50 

mark USER_TYPE 60 to show registered user status 
modify data in SESSION_TIMESTAMP 54 and update session 

cookie 40 
create or update authcode cookie 42 
send session cookie 40 and authcode cookie 42 to 

registered client 46 
obtain and store information about registered client 46 
Process D: Guest Client chooses to become Registered Client. 

30 
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Process D begins by directing guest client 44 to a registration web page where they provide 
confidential information and select a login ID and a password. Data from the NAME attribute of 
session cookie 40 corresponding to the data stored in USERJD 50 is then extracted and used to 
access the correct guest client entry in USER_SESSION table 36. The value in USERJTYPE 60 
is then changed to registered' or another suitable identifier for guest client 44. Guest client 44 is 
now considered to be registered client 46. The timestamp in SESSIONJTIMESTAMP 84 is 
updated. Session cookie 40 is then modified using the new data contained in 
SESSIONJTIMESTAMP 54. Next, if authcode cookie 42 does not exist it is created, otherwise it 
is modified. Authcode cookie 42 is then modified by updating the timestamp stored in 
AUTHCODEJTIMESTAMP 58 and using this updated timestamp to modify the NAME attribute 
of authcode cookie 42. Session cookie 40 and authcode cookie 42 are then sent to the web browser 
of registered client 46. The login ID, password and other important information entered by 
registered client 46 is then obtained from the data entered at the registration web page. The login 
ID is stored in LOGINJD 62 in USER_SESSION table 36 and the password is stored in 
PASSWORD 64 in USER_SESSION table 36. Other information obtained is stored elsewhere in 
database 24. 

Another component process handles the situation in which a guest client 44, who is already 
registered with web site 20, logs on to be recognized as a registered client 46. The pseudocode is 
shown as Process E. 

guest client 44 enters login ID and password 
if login ID and password are not valid then 

direct guest client 44 back to login web page 
else 

find guest client entry in USERJSESSION table 36 
update data contained in SESSIONJTIMESTAMP 54 
update session cookie 40 

update data contained in AUTHCODE_TIMESTAMP 58 
update authcode cookie 42 

send session cookie 40 and authcode cookie 42 to 

registered client 46 
delete guest client entry in USER^SESSION table 36 

Process E: Guest Client logs on as a Registered Client. 
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Process E begins when guest client 44 is directed to a login web page on web site 20 where 
they enter their login ED and password. If the login ID and password are not valid then web server 
1 2 informs guest client 44 that either an invalid login ID and/or password was entered and that guest 
client 44 must re-enter this information. As one skilled in the art will recognize, the login process 
5 may be terminated after a certain number of invalid attempts to login. When the correct login ID 
and password are entered, the login ID and password are used to find the correct guest client entry 
in USER.SESSION table 36. Next, the timestamp in SESSIONJTMESTAMP 54 is updated and 
session cookie 40 is then updated based on this new timestamp value. Next, the timestamp in 
AUTHCODE_HMESTAMP 58 is updated and authcode cookie 42 is then updated based on this 

1 0 new timestamp value. Next, session cookie 40 and authcode cookie 42 are sent to the web browser 
of guest client 44. The last step is an optional step to delete the guest client account that was set up 
for guest client 44 when web site 20 was first accessed. Alternatively, the administrator of web site 
20 can use other utilities, provided by web server software package 18, to remove guest client 
accounts that become stale (i.e. that are not used for a predetermined amount of time such as two 

15 days). 

Another component process is used for verifying session cookie 40 when web client 16 
requests access to a non-secure web page 34 on web site 20. This process ensures that session 
cookie 40 has not been tampered with. The pseudocode is shown below as Process F. 
obtain data in session cookie 40 corresponding to 

USER_ID 50 
get stored data in SESSION_ID 52 and 

SESSIONJTIMESTAMP 54 
regenerate session cookie 40 

if regenerated session cookie = web client's session 
cookie 40 

process request of web client 16 
else 

deny request 
Process F: Session Cookie Verification. 

30 
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Process F begins by extracting data from the NAME attribute of session cookie 40 
corresponding to the data stored in USERJD 50. This data is then used to find the entry for web 
client 16 in USER_SESSION table 36 to obtain the stored values in SESSION JD 52 and 
SESSIONJTIMESTAMP 54. These stored values are used to regenerate session cookie 40. 
5 Regenerated session cookie 40 is then compared to session cookie 40 provided by web client 16. 
If the comparison results in equality then the request of web client 16 is processed. However, if the 
comparison does not result in equality then web client 1 6 may be an unauthorized user so web server 
1 2 denies the request of web client 1 6 to access non-secure web page 34 and sends an error web page 
to the web browser of web client 16. 
10 Another component process is used for verifying authcode cookie 42 when web client 16 

requests access to secure web page 32 on web site 20. This process ensures that authcode cookie 42 
has not been tampered with. In this process, web client 16 is using the HTTPS communication 
protocol and has both session cookie 40 and authcode cookie 42. The pseudocode is shown below 
as Process G. 



15 



20 



obtain data in session cookie 40 corresponding to 
USER_ID 50 

get stored data in AUTHCODE 56 and AUTHCODEJTIMESTAMP 58 
regenerate authcode cookie 42 

if regenerated authcode cookie = web client's authcode 
cookie 42 

process request of web client 16 

else 

deny request 



25 



Process G: Authcode Cookie Verification. 



Process G begins by extracting data from the NAME attribute of session cookie 40 
corresponding to the data stored in USERJD 50. This data is then used to find the entry for web 
client 1 6 in USER_SESSION table 36 to obtain the stored values contained in AUTHCODE 56 and 
AUTHCODE_TIMESTAMP 58. These stored values are used to regenerate authcode cookie 42. 
30 Regenerated authcode cookie 42 is then compared to authcode cookie 42 provided by web client 1 6. 
If the comparison results in equality then web server 12 processes the request of web client 16. If 
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the comparison does not result in equality then web client 16 may be an unauthorized user so web 
server 12 denies the request of web client 16 to access secure web page 32 and sends an error web 
page to the web browser of web client 1 6. 

Another component process is used to handle the case when registered client 46 logs out of 
5 web site 20. The pseudocode is shown below as Process H. 



Process H: Registered Client Logs out 

Process H begins when registered client 46 chooses to log out of web site 20. Next, web 
server 12 updates session cookie 40 and authcode cookie 42 such that all attributes contain NULL 

15 values. Web server 12 then sends updated session cookie 40 and updated authcode cookie 42 to the 
web browser of registered client 46. Alternatively, registered client 46 may not log out and simply 
visits another web site in which case both session cookie 40 and authcode cookie 42 will remain in 
the memory of the web browser used by registered client 46. If registered client 46 revisits web site 
20 then the web browser of registered client 46 will send session cookie 40 back to web server 12. 

20 Alternatively, registered client 46 may simply quit their web browser application without logging 
out of web site 20 in which case session cookie 40 and authcode cookie 42 will be destroyed since 
they are preferably temporary cookies. 

Another component process handles the situation in which registered client 46 requests 
access to secure web page 32 but does not possess authcode cookie 42. The pseudocode is shown 

25 below as Process I. 



registered client 46 chooses to log out 

web server 12 updates session cookie 40 and authcode 



cookie 42 



web server 12 sends session cookie 40 and authcode 



10 



cookie 42 to registered client 46 
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previously registered web client 16 requests access to 
secure web page 32 and does not have authcode cookie 42 
if registered web client has authcode cookie 

process request 
else 

force previously registered web client 16 to log on 
if login ID and password are valid 

create authcode cookie 42 and send to registered 

client 46 

process request for secure web page 32 
else 

deny request 

Process I: Registered Client accesses Secure Web page without authcode 
cookie. 

Process I begins when web client 16, who is already registered with web site 20 (i.e. previously 
registered web client 1 6), attempts to access secure web page 32 but has not yet logged onto web site 
20 to indicate that they are a registered client 46. Next, previously registered web client 16 is 
checked to see if they have authcode cookie 42. Since previously registered web client 16 does not 
have authcode cookie 42, previously registered web client 16 is forced to log on to web site 20 by 
entering their login ID and password at the login web page. Next, the login ID and password are 
verified. If verification fails, then web server 12 denies the request of previously registered web 
client 1 6 to access secure web page 32 and sends an error web page to the web browser of previously 
registered web client 16. However, if the login ID and password are valid, then authcode cookie 42 
is created and sent to the web browser of previously registered web client 1 6. Previously registered 
web client 16 is then recognized as a registered client 46. The request of registered client 46 to 
access secure web page 32 is then granted. 

In practice, there are three general usage scenarios for web site 20 in accordance with the 
session management and authorization scheme outlined in the present invention. In general, either 
web client 16 accesses web site 20 and is a guest client 44 throughout the entire session with web 



CA9-2000-0054 



21 



CA 02327078 2000-11-30 



site 20 (see Figures 4a and 4b), or web client 1 6 accesses web site 20 and becomes a registered client 
46 (see Figures 5a, 5b and 5c), or web client 1 6 accesses web site 20, is already registered, and logs 
on as a registered client 46 (see Figures 6a and 6b). Bear in mind that although Figures 4a, 4b, 5a, 
5b, 5c, 6a and 6b show web client 1 6 first accessing a plurality of non-secure web pages 34, followed 
by accessing a plurality of secure web pages 32, the opposite may also happen, i.e. web client 16 
may first access a plurality of secure web pages 32 followed by accessing a plurality of non-secure 
web pages 34. Alternatively, web client 16 may alternate requests to non-secure web pages 34 and 
secure web pages 32. In practice, there can be many usage cases but for the sake of simplicity only 
a few are shown in Figures 6 to 8. 

Referring now to Figures 4a and 4b, the scenario begins at step 80 where web client 16 
accesses web site 20. By default, web client 16 is defined to be a guest client 44. Next, in step 82, 
a guest client account in USERJJESSION table 36 and session cookie 40 are created for guest client 
44. Guest client 44 then goes on to request access to non-secure web page 34 in step 84. Session 
cookie 40 is then verified in step 86. If session cookie 40 is not valid then control passes to step 88 
where web server 1 2 denies the request of guest client 44 for access to non-secure web page 34 and 
sends an error web page to the web browser of guest client 44. Alternatively, if session cookie 40 
is valid then control moves to step 90 where guest client 44 accesses non-secure web page 34. Guest 
client 44 can then access a number of non-secure web pages 34 in which verification of session 
cookie 40 occurs with each access request. Eventually, guest client 44 requests access to secure web 
page 32 in step 94. Web server 12 then checks to see if guest client 44 is using HTTPS in step 95. 
If HTTPS is not being used, then web server 12 informs the web browser of guest client 44 to use 
HTTPS in step 96. If an HTTPS connection is not verified in step 98 then web server 12 denies the 
request of guest client 44 to view secure web page 32 and sends an error web page to the web 
browser of guest client 44 in step 1 00. Otherwise, if guest client 44 is using HTTPS then in step 102 
web server 12 checks whether guest client 44 needs authcode cookie 42 by checking if there is an 
authorization code in AUTHCODE 56 in USER_SESSION table 36. If guest client 44 already has 
an authorization code then control passes to step 1 04 where web server 1 2 denies the request of guest 
client 44 for access to secure web page 32, since guest client 44 may be an unauthorized user at this 
point, and sends an error web page to the web browser of guest client 44. However, if guest client 
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44 does not an authorization code then control passes to step 106 where authcode cookie 42 is 
created and sent to guest client 44. Guest client 44 can then access secure web page 32. Next, in 
step 1 08, guest client 44 requests access to another secure web page 32 on web site 20 at which point 
authcode cookie 42 of guest client 44 is checked to see if it is valid in step 1 10. If authcode cookie 
5 42 is not valid then the process flows to step 1 1 2 where web server 1 2 denies the request for access 
to secure web page 32 and sends an error web page to the web browser of guest client 44. 
Alternatively, if authcode cookie 42 is valid then guest client 44 can access secure web page 32 in 
step 114. Guest client 44 can then access a number of other secure web pages 32 in which 
verification of authcode cookie 42 occurs with each access request. Next, in step 118, guest client 

10 44 does some shopping and in step 120 pays for any goods that were purchased and provides 
shipping information. Guest client 44 then leaves web site 20 by simply closing their web browser 
or accessing a different web site in step 122. Once the web browser of guest client 44 is closed, 
session cookie 40 and authcode cookie 42 are erased since they are temporary cookies. 

Referring now to Figures 5a, 5b and 5c, the scenario begins at step 1 30 where web client 1 6 

1 5 accesses web site 20. By default, web client 1 6 is defined to be a guest client 44. Next, in step 1 32, 
a guest client account is created in USER_SESSION table 36 and session cookie 40 is also created. 
Session cookie 40 is then sent to the web browser of guest client 44. Guest client 44 then decides 
to become a registered client 46 in step 1 34. Web server 12 then checks to see if HTTPS is being 
used by guest client 44 in step 136. If not, then the process flows to step 138 where web server 12 

20 informs the web browser of guest client 44 to use HTTPS. The use of an HTTPS connection is 
checked in step 140. If HTTPS is not used, then the process flows to step 142 where web server 12 
denies the request of guest client 44 to become a registered user and sends an error web page to the 
web browser of guest client 44. Alternatively, if HTTPS is being used by guest client 44, then 
control passes to step 1 44 where authcode cookie 42 is created for guest client 44. Next, in step 146, 

25 guest client 44 is directed to a registration web page on web site 20 where guest client 44 provides 
client information. In step 148, a registered client account is created and guest client 44 becomes 
registered client 46. Registered client 46 can then access non-secure web pages 34, as shown in step 
150, at which point web server 12 verifies session cookie 40 of registered client 46 in step 152. If 
session cookie 40 is not valid, control passes to step 1 54 where web server 1 2 denies the request of 
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registered client 46 for access to non-secure web page 34 and sends an error web page to the web 
browser of registered client 46. Alternatively, if session cookie 40 is valid then registered client 46 
can access non-secure web page 34 in step 1 56. Registered client 46 may then go on to access other 
non-secure web pages 34 in which verification of session cookie 40 occurs with each access request. 
5 In step 1 60, registered client 46 requests access to secure web page 32 after which, in step 1 62, web 
server 12 determines if registered client 46 is using HTTPS. If HTTPS is not being used then web 
server 12 informs the web browser of registered client 46 to switch to HTTPS in step 164. The use 
of HTTPS is then checked in step 1 66. If registered client 46 is not using HTTPS, then the process 
flows to step 168 where web server 12 denies the request of registered client 46 to access secure web 

10 page 32 and sends an error web page to the web browser of registered client 46. Alternatively, if 
HTTPS is being used, then control passes to step 1 70 where web server 12 verifies authcode cookie 
42. If authcode cookie 42 is not valid then the process flows to step 172 where web server 12 denies 
the request of registered client 46 for access to secure web page 32 and sends an error web page to 
the web browser of registered client 46. Alternatively, if authcode cookie 42 is valid, then registered 

1 5 client 46 can access secure web page 32 in step 1 74. Registered client 46 may then go on to access 
a number of secure web pages 32 in which verification of authcode cookie 42 occurs with each 
access request. Registered client 46 can also shop as seen in step 1 78. If registered client 46 makes 
purchases then in step 1 80, registered client 46 pays for the purchases and web server 12 stores data 
about the purchases made in database 24. Next, in step 1 82, registered client 46 either logs out of 

20 web site 20, accesses another web site or simply quits their web browser application. Regardless of 
the choice made by registered client 46, once registered client 46 quits their web browser application, 
session cookie 40 and authcode cookie 42 are destroyed because they are preferably defined as 
temporary cookies. 

Referring now to Figures 6a and 6b, the scenario begins at step 1 90 where web client 1 6, who 
25 has already registered with web site 20, accesses web site 20. Web client 16 is defined as guest 
client 44 by defeult. A guest client account is then created in USER_SESSION table 36 and session 
cookie 40 is created and sent to guest client 44. Guest client 44 then decides to log on in step 192 
at which point web server 12 must determine if guest client 44 is using HTTPS in step 194. If not, 
then web server 12 informs the web browser of guest client 44 to use HTTPS in step 196. The use 
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of HTTPS is checked in step 198. If HTTPS is not being used, then the process flows to step 200 
where web server 12 denies the request of guest client 44 to log on and sends an error web page to 
the web browser of guest client 44. Alternatively, if guest client 44 is using HTTPS, then the 
process flows to step 202 where authcode cookie 42 is created or updated and sent to the web 
5 browser of guest client 44. Next, in step 204, guest client 44 logs on and becomes registered client 
46. Registered client 46 can then access non-secure web page 34 on web site 20 in step 206 at which 
point web server 12 verifies session cookie 40 in step 208. If verification fails, the process flows to 
step 210 where web server 12 denies the request of registered client 46 to access non-secure web 
page 34 and sends an error web page to the web browser of registered client 46. Alternatively, if 

1 0 session cookie 40 is valid then the process flows to step 2 1 2 where registered client 46 accesses non- 
secure web page 34. Registered client 46 can then go on to access a number of non-secure web 
pages 34 in which verification of session cookie 40 occurs with each access request. Next, in step 
216, registered client 46 requests access to secure web page 32. Web server 12 then checks to see 
if HTTPS is being used by registered client 46 in step 218. If HTTPS is not being used, then web 

1 5 server 12 informs the web browser of registered client 46 to use HTTPS in step 220. The usage of 
HTTPS is checked in step 222. If HTTPS is not being used, then the process flows to step 224 
where web server 12 denies the request of registered client 46 to access secure web page 32 and 
sends an error web page to the web browser of registered client 46. Alternatively, if registered client 
46 is using HTTPS, then the process flows to step 226 where authcode cookie 42 is verified. If 

20 verification fails, the process flows to step 228 where web server 1 2 denies the request of registered 
client 46 to access secure web page 32 and sends an error web page to the web browser of registered 
client 46. Alternatively, if verification is successful, then registered client 46 can access secure web 
page 32 in step 230. Registered client 46 can also shop and/or check their order history as shown 
in step 234. If any purchases are made, then registered client 46 pays for these purchases and web 

25 server 1 2 stores data about these purchases in database 24 in step 236. Registered client 46 can then 
leave web site 20 in step 238 by logging out, accessing a different web site or simply quitting their 
web browser application. Regardless of the choice made by registered client 46, once registered 
client 46 quits their web browser application, session cookie 40 and authcode cookie 42 are 
destroyed because they are preferably defined as temporary cookies. 
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The system and method implemented in the present invention is designed to prevent access 
by unauthorized users to sensitive information about web site 20 or web client 16. For instance, if 
web client 16 is a guest client 44 without authcode cookie 42, i.e. guest client 44 has not accessed 
any secure web pages 32, then there is no secure information associated with guest client 44. The 
5 unauthorized user can not do anything harmful in this case. Another situation would be if web client 
16 is a guest client 44 with authcode cookie 42 (i.e. web client 1 6 has already accessed a secure web 
page 32). In this case, an unauthorized user's attempt will fail since the unauthorized user can only 
use session cookie 40, does not have authcode cookie 42 and web server 12 already knows that guest 
client 44 has authcode cookie 42 (by checking AUTHCODE 56 in USER_SESSION table 36). 

1 0 Another alternative situation would be if web client 1 6 is a registered client 46 and an unauthorized 
user tries to use session cookie 40 to browse secure web pages 32. Since the unauthorized user does 
not have authcode cookie 42, web server 1 2 will redirect the unauthorized user to the login web page 
at which point the unauthorized user won't be able to log on since they do not have the login ID or 
password of registered client 46. 

15 To recapitulate, the present invention allows for either a non-secure (HTTP) or secure 

(HTTPS) communication protocol to be used when a web client accesses a non-secure web page or 
a secure web page, respectively, at a web site. This provides for a secure and efficient session 
between the web client and the web site. Further, two distinct cookies are used, a session cookie (for 
session management) and an authcode cookie (for authentication). The session cookie is also 

20 designed such that it does not contain sensitive information about the web client. Finally, the web 
site allows for either guest client or registered client access which increases the flexibility and user 
appeal of the web site. 

It should be mentioned that although the present invention has been described in the context 
of an e-commerce web site, it is not the intent of the inventor to restrict the use of the present 
25 invention to the use of e-commerce alone. For instance, the present invention may be used to secure 
the exchange of data for non e-commerce functions such as online voting, issuing credit card 
numbers, online stock trading and the like. 

The present invention may also be readily adapted to utilize name-value pairs for 
authentication and session management between the web site and the web client by directing web 
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server 12 to generate a session name-value pair and passing this session name-value pair to every 
web page 22 on web site 20. Web server 12 also generates an authcode name- value pair and passes 
it to every secure web page 32 on web site 20. 

It is to be understood that what has been described are preferred embodiments to the 
invention. The invention nonetheless is susceptible to certain changes and alternative embodiments 
fiilly comprehended by the spirit of the invention as described above, and the scope of the claims set 
out below. 



CA9-2000-0054 



27 



CA 02327078 2000-11-30 




CLAIMS 

The embodiments of the invention in which an exclusive property or privilege is claimed are defined 
as follows: 

5 1 . A method of secure session management and authentication between a web site and a web 
client, said web site having secure and non-secure web pages, said method comprising the steps of: 

a) utilizing a non-secure communication protocol and a session cookie when said web 
client requests access to said non-secure web pages; and 

b) utilizing a secure communication protocol and an authcode cookie when said web 
10 client requests access to said secure web pages. 

2. The method of claim 1 , wherein said method also comprises the steps of: 

c) requesting said session cookie from said web client when said web client requests 
access to said non-secure web pages and verifying said requested session cookie; and 

1 5 d) requesting said authcode cookie from said web client when said web client requests 

access to said secure web pages and verifying said requested authcode cookie. 

3 . The method of claim 2, wherein said method also comprises alternating between said secure 
communication protocol and said non-secure communication protocol when said web client 

20 alternates requests for access to said secure web pages and said non-secure web pages. 

4. The method of claim 3, wherein said alternating between said secure communication protocol 
and said non-secure communication protocol is facilitated by a table which keeps track of said non- 
secure web pages and said secure web pages. 

25 

5. The method of claim 4, wherein said web site uses said table to direct said web client to use 
said secure communication protocol or said non-secure communication protocol depending on 
whether said web client requests access to said non-secure web pages or said secure web pages. 
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6. The method of claim 3, wherein said method also comprises allowing said web client to be 
a guest client or a registered client. 

7. The method of claim 6, wherein said method also comprises creating stored information 
5 including data contained in said session cookie, data contained in said authcode cookie and data 

about said web client 

8. The method of claim 3, wherein said non-secure communication protocol is HTTP. 
10 9. The method of claim 3, wherein said secure communication protocol is HTTPS. 

10. The method of claim 7, wherein said session cookie includes a pointer and an encrypted 
portion, said pointer pointing to said stored information, said encrypted portion having a random 
portion and a date portion. 

15 

1 1. The method of claim 10, wherein said session cookie is either a temporary cookie or a 
permanent cookie. 

12. The method of claim 7, wherein said authcode cookie includes an encrypted portion, said 
20 encrypted portion having a random portion and a date portion. 

1 3. The method of claim 12, wherein said authcode cookie is temporary. 

14. The method of claim 10, wherein verifying said requested session cookie from said web 
25 client includes using said stored information to generate a second session cookie and comparing said 

second session cookie to said session cookie requested from said web client. 

15. The method of claim 12, wherein verifying said requested authcode cookie from said web 
client includes using said stored information to generate a second authcode cookie and comparing 



CA9-2000-0054 



29 



CA 02327078 2000-11-30 

* 



said second autocode cookie to said autocode cookie requested from said web client. 

1 6. A system, for secure session management and authentication between a web site and a web 
client, said system comprising a web server, a web client and a communication channel, said web 

5 server coupled to said web client via said communication channel, said web server having a web site, 
said web site including: 

a) secure and non-secure web pages; 

b) a non-secure communication protocol and a session cookie for allowing said web 
client access to said non-secure web pages; and 

10 c) a secure communication protocol and an autocode cookie for allowing said web 

client access to said secure web pages. 

1 7. The system of claim 1 6, wherein said web site also includes: 

d) verification means for verifying said session cookie when said session cookie is 
15 requested from said web client; and 

e) verification means for verifying said autocode cookie when said autocode cookie 
is requested from said web client. 

18. The system of claim 17, wherein said web server further comprises a security alternating 
20 means for alternating between said secure communication protocol and said non-secure 

communication protocol. 

19. The system of claim 1 8, wherein said web server further comprises a table to keep track of 
said non-secure web pages and said secure web pages. 

25 

20. The system of claim 1 7, wherein said web site includes access means to allow said web client 
to access said web site as a guest client or a registered client 

2 1 . The system of claim 20, wherein said web system has storage means for containing stored 
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information about said web client, data contained in said session cookie and data contained in said 
authcode cookie. 

22. The system of claim 18, wherein said non-secure communication protocol is HTTP. 



23. The system of claim 18, wherein said secure communication protocol is HTTPS. 

24. The system of claim 21, wherein said session cookie includes a pointer and an encrypted 



25. The system of claim 24, wherein said session cookie is a temporary cookie or a permanent 
cookie. 

1 5 26. The system of claim 2 1 , wherein said authcode cookie includes an encrypted portion, said 
encrypted portion having a random portion and a date portion. 

27. The system of claim 26, wherein said authcode cookie is temporary. 

20 28. A computer program embodied on a computer readable medium, said computer program 
providing for secure session management and authentication between a web site and a web client, 
said web site having secure and non-secure web pages, said computer program adapted to: 

a) use a non-secure communication protocol and a session cookie when said web 
client requests access to said non-secure web pages; and 

25 b) use a secure communication protocol and an authcode cookie when said web client 

requests access to said secure web pages. 

29. The computer program of claim 28, wherein said computer program is further adapted to: 
c) request said session cookie from said web client when said web client requests 



5 



10 



portion, said pointer pointing to said stored information, said encrypted portion having a random 
portion and a date portion. 
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access to said non-secure web pages and to verify said requested session cookie; and 

d) request said authcode cookie from said web client when said web client requests 
access to said secure web pages and to verify said requested authcode cookie. 

5 30. The computer program of claim 29, wherein said computer program is further adapted to 
alternate between said secure communication protocol and said non-secure communication protocol 
when said web client alternates requests for access to said secure web pages and said non-secure web 
pages. 

10 31. The computer program of claim 30, wherein said alternating between said secure 
communication protocol and said non-secure communication protocol is facilitated by a table which 
keeps track of said non-secure web pages and said secure web pages. 

32. The computer program of claim 3 1 , wherein said computer program uses said table to direct 
15 said web client to use said secure communication protocol or said non-secure communication 

protocol depending on whether said web client requests access to said non-secure web pages or said 
secure web pages. 

33. The computer program of claim 30, wherein said computer program is adapted to allow said 
20 web client to be a guest client or a registered client. 

34. The computer program of claim 33, wherein said computer program is adapted to create 
stored information including data contained in said session cookie, data contained in said authcode 
cookie and data about said web client. 

25 

35. The computer program of claim 30, wherein said non-secure communication protocol is 
HTTP. 

36. The computer program of claim 30, wherein said secure communication protocol is HTTPS. 
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37. The computer program of claim 34, wherein said session cookie includes a pointer and an 
encrypted portion, said pointer pointing to said stored information, said encrypted portion having 
a random portion and a date portion. 

5 38. The computer program of claim 37, wherein said session cookie is either a temporary cookie 
or a permanent cookie. 

39. The computer program of claim 34, wherein said authcode cookie includes an encrypted 
portion, said encrypted portion having a random portion and a date portion. 

10 

40. The computer program of claim 39, wherein said authcode cookie is temporary. 



41. The computer program of claim 37, wherein verifying said requested session cookie from 
said web client includes using said stored information to generate a second session cookie and 

1 5 comparing said second session cookie to said session cookie requested from said web client. 

42. The computer program of claim 39, wherein verifying said requested authcode cookie from 
said web client includes using said stored information to generate a second authcode cookie and 
comparing said second authcode cookie to said authcode cookie requested from said web client. 

20 

43. A computer program comprising computer code means adapted to perform all the steps of 
claims 1, 2, 3, 6, and 7. 

44. The computer program as claimed in claim 43 embodied on a computer readable medium. 

25 

45. A computer program for creating a NAME attribute in a session cookie, said computer 
program comprising the steps of: 

a) generating a userjd; 

b) generating a session_string; 
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25 



value; 



and 



c) generating a session_timestamp; 

d) appending said session_timestamp to said sessionjtring to create an intermediate 

e) applying a one way hash fttnction to said intermediate value to create a final value; 

f) storing said final value in said NAME attribute. 



46. The computer program of claim 45, wherein creating a PATH attribute, an EXPIRES 
attribute, a DOMAIN attribute and a SECURE attribute in said session cookie comprises the steps 

10 of: 

a) storing a slash (6/6) in said PATH attribute; 

b) storing a null string (66) in said EXPIRES attribute; 

c) storing a null string (66) in said DOMAIN attribute; and 

d) storing a null string (66) in said SECURE attribute. 

15 

47. A computer program for creating a NAME attribute in an authcode cookie, said computer 
program comprising the steps of: 

a) generating an authcode; 

b) generating an authcode_timestamp; 

20 c) appending said authcode_timestamp to said authcode to create an intermediate 

value; 

d) applying a one way hash function to said intermediate value to create a final value; 

and 

e) storing said final value in said NAME attribute. 



48. The computer program of claim 47, wherein creating a PATH attribute, an EXPIRES 
attribute, a DOMAIN attribute and a SECURE attribute in said authcode cookie comprises the steps 
o£ 

a) storing a slash (6/6) in said PATH attribute; 
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b) storing a null string (66) in said EXPIRES attribute; 

c) storing a null string (66) in said DOMAIN attribute; and 

d) storing the string 6secure6 in said SECURE attribute. 



49. A computer program product comprising: 

a computer readable signal-bearing medium; 

means in said medium for accomplishing the method of any of claims 1 to IS. 

50. The product of claim 49 wherein said medium is a recordable data storage medium. 

5 1 . The product of claim 49 wherein said medium is a modulated carrier signal. 

52. The product of claim 5 1 wherein said signal is a transmission over a network 

53. The product of claim 52 wherein said network is the Internet. 
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